Individuals and businesses often seek ways to prevent the unintended loss of valuable data. For example, an entity may back up data by replicating the data from one storage unit to another storage unit. In some cases, the original storage unit, and/or the destination storage unit, may belong to a data cluster.
Data clusters often use replication logs to record I/O operations performed on either the original storage unit or the destination storage unit. Since a replication log may be separated from its corresponding storage unit, a data cluster may be able access this log even if it is unable to access the corresponding storage unit, or vice versa.
In conventional systems, if a data cluster is unable to access an object (e.g., a storage unit or log) required to replicate data from one storage unit to another, the data cluster may either (1) allow the I/O operation to continue but fail replication or (2) fail both the I/O operation and replication. In either case, however, replication fails.
Replication failure is undesirable for numerous reasons. For example, replication failure may require that all data be completely resynchronized. Replication failure may also lead to data inconsistencies on the destination site. Given the limited bandwidth that is typically available between source and designation (i.e., recovery) sites, even optimized resynchronization solutions may introduce a significant performance overhead.